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(57) Abstract: The invention concerns a 
method for generating applicative software 
for management of a process using a system 
software common to all the applicative 
software. It comprises: a step of representing 
the process (32), using a very small number of 
classes of actions or generic objects, typically 
less than twenty, in at least a diagram of 
the application; a step of transcribing (33) 
each object of each diagram into an action 
corresponding to an object provided with 
attributes, each class of action or generic object 
being, during the transcription step, associated 
with an application data input interface; a 
step of transcribing the nodes, branches and 
end-nodes (34) of each diagram into an action 
corresponding to an object provided with 
attributes, a step of pre-compiling (35) which 
consists in verif5nng whether the attributes 
of the objects required for the application 
operational logic exist and are properly 
supplied, in syntax; a compilation (36) which 
consists in integrating and assembling the data 
specifications of the objects provided with 
attributes with the system software, to obtain 
an executable applicative software; and a step 
of executing (37) the executable applicative 
software. 
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(57) Abr^g^ : Le proc6d6 de g^n^ration de logiciel applicatif de gestion d'un processus met en oeuvre un logiciel syst^me commun 
k tous les logiciels applicatifs. II comporte: une 6tape de representation du processus (32), mettant en oeuvre un tr^s petit nombre 
de classes d* actions ou objets g6n6riques, typiquement inKrieur k vingt, dans au moins un diagramme de Tapplication, une ^tape 
de transcription (33) de chaque objet de chaque diagramme en une action correspondant h un objet doi6 d*attributs, chaque classe 
d'action ou objet g^n^rique 6tant. pendant I'^tape de transcription. associ6 k une interface de saisie de donnas d' application, une 
^tape de transcription des noeuds, embranchements et feuilles (34) de chaque diagramme en une action correspondant h un objet 6ot6 
d'attributs. une ^tape de pr6-compilation (35) au cours de laquelle on v^rifie que les attributs des objets n^cessaires pour la logique 
de fonctionnement de Tapplication existent et sont convenablement foumis, en syntaxe, une 6tape de compilation (36) au cours de 
laquelle les descriptifs de donn6es des objets dot6s d'attributs sont int6gr6s et sont assembles avec le logiciel syst^me, pour obtenir 
un logiciel applicatif executable, et une ^tape d' execution (37) du logiciel applicatif executable. 
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PROCEDE ET DISPOSITIF DE GENERATION DE LOGICIELS EXECUTABLES SUR 
MESURE ET EVOLUTIFS SANS PROGRAMMATION INFORMATIQUE 

La presente invention vise un procede et dispositif de generation de logiciels 
5 executables sur mesure et evolutifs sans programmatipn informatique. Elle 
s'applique en particulier a la generation de logiciels de gestion et de pilotage d*un 
centre de profits. 

Le processus de generation de logiciels actuellement connu est base sur la 
negociation d'un cahier des charges entre le client et Tinformaticien charge de 

10 realiser une application informatique repondant au cahier des charges, puis la 
programmation par un informaticien d*un logiciel correspondant au cahier des 
charges negocie. Le client ne maTtrisant pas les contraintes techniques qui encadrent 
le travail de rinformaticien. la negociation est asymetrique et provoque. par elle- 
meme, une insatisfaction du client. En outre, toute modification ulterieure du logiciel 

15 est soumise a un nouveau travail de rinformaticien, ce qui gene revolution de ce 
logiciel. 

La presente invention vise a rem6dier a ces inconvenients. En particulier, la 
presente invention vise a 6viter intervention d'un informaticien dans la 
programmation ou la modification d'un logiciel. En d'autres mots, la presente 
20 invention vise a donner au client : 

- la maTtrise du processus operationnels de g^nSration de i'application. 

- d'eviter que Tapplication soit soumise aux modeles sommaires donnes par les 
informaticiens, 

- d'obtenir, en quelques minutes, une application informatique sur mesure, 
25 repondant integralement a ses voeux, sans avoir a maitriser de langage 

informatique. 

Selon un aspect, la presente invention vise un procede de generation de 
logiciel applicatif de gestion d'un processus, caract6ris§ en ce qu'il met en oeuvre un 
logiciel systSme commun a tous les logiciels applicatifs et en ce qu'il comporte : 
30 - une etape de representation du processus, mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets gen^riques, typiquement inferieur d vingt, 
dans au moins un diagramme de Tapplication, 
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- une 6tape de transcription de cheque objet de cheque diagramme en une action 
correspondant a un objet dote d'attributs, cheque classe d'action ou objet 
generique etant. pendant I'etape de transcription, associe a une interface de 
saisie de donnees d'application, 

5 - une etepe de transcription des noeuds, embranchements et feuilles de cheque 
diagremme en une action correspondent e un objet dote d'ettributs. 

- une etepe de pre-compiletion eu cours de lequelle on v6rifie que les ettributs 
des objets necesseires pour la logique de fonctionnement de Tapplicetion existent 
et sont conveneblement fournis, en syntexe, 

10 - une etepe de compiletion eu cours de lequelle les descriptifs de donnees des 
objets dotes d'ettributs sont integres et sont essembles evec le logiciel systeme, 
pour obtenir un logiciel epplicatif executeble, et 

- une etepe d'execution du logiciel epplicetif executeble. 

Grece e ces dispositions, le client effectue le representetion du processus 

15 correspondent e rapplication per une simple representetion grephique en 
diegremme, qui definit integrelement Tepplicetion informetique qu'il souheite. sens 
autre contreinte que celle de conneitre le tres petit nombre d'objet generiques e 
employer. D§s que cette phese est echev6e, le trenscrlption peut etre effectu6e per 
simple seisie. per une personne de faible quelificetion. Les deux etepes restentes. 

20 pre-compiletion et compilation sont totalement autometiques. 

On obsen^e que les descriptifs d'epplicetions peuvent etre modifies ou 
completes eisement : une nouvelle compiletion fournit un executeble e jour, 
competible evec les eutres versions, et evolutif, en quelques minutes. 

On observe qu'essembler un certain nombre d'ections stendards en un 

25 diegramme donne un resultet plus simple e controler que du code (per exemple du 
code "C") genere directement. Le principe est que des ections, qui treveillent sur des 
donnees conveneblement orgenis^es, peuvent etre considerees comme sures. et 
leur contenu jemeis trec6, ce qui evite de longues phases de debuggage. 

Les dSroulements de ces diagremmes sont fixes de fa^on permanente dans 

30 des procedures standerd. II sufTit de fournir les identificateurs d'ecrans et de fichiers 
utilises, et ces diagremmes vont les visueliser, modifier les menus eu fur et e mesure 
des etepes, etc ... Le mecenisme de le procedure est toujours identique, meis son 
contenu est edept^, sur mesure. eux besoins exprimes per les utiliseteurs. Bien 
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entendu. un certain nombre de points d'entree subsiste pour inserer des actions 
particulieres a chaque client, par exemple si le mode de lecture des donnees est tres 
particulier (par exemple. si le fichier n'est pas un fichier standard mais est importe 
d'un autre systeme. la fa^on de lire la premiere fiche n'est pas standard, done doit 
5 etre donn6e par le concepteur). Par centre, le fait d'avoir le choix de demander la 
premiere fiche reste standard, done le diagramme considere est utilisable. 
L'ensemble des informations propres a chacun des applicatifs est reuni de fa9on 
structuree dans des "cartes" : le concepteur "cable" une carte pour approprier le 
processus standard a chaque processus particulier. 

10 Ce principe permet, par exemple. a une m§me action de visualisation 

d'afficher des ecrans differents suivant la carte dans laquelle on se trouve, tout en 
conservant les memes parametres d'appel. II suffit d'avoir modifie auparavant une 
table de parametres indexes. 

Ce type d'interpretation est fait non pas par Taction elle-meme. mais par le 

15 mecanisme d'interpretation des diagrammes ("cablage" de la carte). En d*autres 
tennes, une action comporte des donnees soit decrites de fa^on specifique soit 
decrites par des parametres (carte + numero dans la carte). 

Selon des caracteristiques particulieres. au cours de Tetape de transcription 
d'objets, au moins une action lance un traitement complet se trouvant S un endroit 

20 distant d'une arborescence correspondent audit au moins un diagramme, et une fois 
celui-ci termine, retourne ^ son point de d6part. 

Grace a ces dispositions, les diagrammes peuvent etre constitues, modifies et 
mis a jour independamment. 

Selon des caracteristiques particulieres, au cours de Tetape d'execution, le 

25 logiciel applicatif executable met en oeuvre une bibliotheque de gestion du 
deroulement des processus correspondent audit au moins un diagramme, ladite 
bibliotheque constituent un automate qui gere le deroulement des processus et 
execute les operations qui les jalonnent, le deroulement des operations etant d^fini, 
dans le r6f6rentiei applicatif, a Taide de la m^thode, en decrivant les flux r^els. 

30 Ainsi, ia'seule mise en oeuvre de la mSthode et de la transcription permet de 

programmer une application. 
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Selon des caracteristiques particulieres. au cours de Tetape de compilation ou 
au cours de I'etape d'execution. il met en oeuvre un moteur qui comporte un 
superviseur charge de reconnaitre la configuration materielle et de communication. 

Grace a ces dispositions, il est inutile de generer la configuration dans 
5 Tapplicatif. La gestion des echanges se fait par des taches sur I'ensemble d'un 
ecran. sur certains champs ou par des messages envoyes a I'utilisateur par le 
d^roulement du processus. 

Selon des caracteristiques particulieres, le moteur gere une ou plusieurs 
bases de donnees d'apres un descriptif des fichiers de donnees fourni par le 
10 referentiel applicatif, c'est-a-dire une liste des informations contenues dans chaque 
fiche et la liste des index d'acces. avec une liste des champs servant a constituer 
chacun de ces index, les liens entre des codifications multiples d'un meme item dans 
plusieurs sen/ices, plusieurs sites ou plusieurs entreprises. 

Selon des caracteristiques particulieres, les bases de donnees sont 
15 synchronisees selon une frequence determinee par le diagramme, a la demande ou 
avant certains evenements predetermines. 

Ainsi, les bases de donnees peuvent etre synchronisees toutes les nuits, 
iorsqu*un utilisateur autorise le demande ou pour un evenement le n^cessitant, par 
exemple pour realiser un devis client (les stocks et les prix instantanes devant. par 
20 exemple, etre connus pour cette operations). 

Selon des caracteristiques particulieres, I'etape de transcription d*objets 
comporte, pour programmer chaque action : 

- une etape de nommage au cours de laquelle on donne un nom a ladite action, 

- une etape de definition de fonction. au cours de laquelle on met ladite action en 
25 correspondance avec une tache, et. 

- une etape de definition d'information. au cours de laquelle on designe les 
informations qui seront traitees dans Taction. 

Les actions sont enchamees suivant leur ordre fonctionnel dans des 
diagrammes. Les actions ramenant toutes d des codes dSfinis, 11 est possible de 
30 representer ainsi ies structures de contrdle classiques telles que branchement. 
boucle, test, etc ... Ces controles sont eux-memes effectues par des actions. 
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Selon des caracteristiques particulieres, I'etape de compilation remplace le 
nom d'action donne. au cours de I'etape de nommage. par le transcripteur. par un 
index dans une table de taches. 

Grace a ces dispositions, Tetape de transcription peut etre assez intuitive, le 
5 transcripteur choisissant un nom d'action qui lui semble ais6ment reconnaissable, 
tout en permettant un fonctionnement automatique et efficace de Tapplication 
compilee. 

D'autres avantages, buts et caracteristiques de la presente invention 
ressortiront de la description qui va suivre, faite en regard des dessins annexes dans 
10 lesquels : 

- la figure 1 represente, schematiquement. les composants du systeme objet 
de la presente invention, 

- la figure 2 represente, schematiquement, des composants mis en oeuvre par 
le precede objet de la presente invention, et 

15 - la figure 3 represente, schematiquement, les etapes mises en oeuvre par le 

proc6de objet de la pr6sente invention. 

Dans la figure 1 sont representes une methode 10 de description de 
processus et de generation de diagramme 150, un generateur d'application 
informatique 20 mettant en oeuvre des objets generiques 30, des composants 

20 proceduraux 40 et des composants applicatifs 50 pour g^nerer un logiciel executable 
60 comportant un automate 70 mettant en oeuvre les composants applicatifs 50. 

Conformement a la methode 10. methode de description cybernetique des 
processus, de quelque nature qu'ils soient, pour obtenir un descriptif sous forme de 
macro-langage, appele "referentiel applicatif le client definit d'abord sont processus 

25 en grands ensembles, en decrivant leurs relations (par exemple gestion des stocks, 
comptabilite, decision d'organisation de travail, prise de commande. alertes 
necessaires ...). Dans un second temps, chaque ensemble est considere et 
decompose en sous-ensembles de taches, et ainsi que suite jusqu'a ce que toutes 
les actions du processus soient decrites en ne mettant en oeuvre que des 

30 diagrammes composes d'actions correspond ant, chacune a un d'objet generique de 
I'une des classes suivantes. dote d'attributs necessaires au fonctionnement des 
diagrammes : 

a) entreposage structure de dorihees, 
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b) transmission de donnees, 

c) supervision, 

d) communication avec les utilisateurs, 

e) d^roulement du processus. 

5 f) systeme op§rationnel (capteurs de donn6es et de signaux, emission de 

messages et d'alertes), 

g) pilotage ^ deux niveaux (previsionnel ou operationnel). 

Le macro-langage d6fini par la methode 10 decrit les processus pour 
constituer une couche logique. au dessus de la couche des programmes 
10 informatiques. A la base de la creation de ce macro-langage, 11 a ete cree une 
typologie des traitements informatiques. 

On observe que le diagramme lui-meme est compose d'une racine, 
d'embranchements, de noeuds et de feuilles, chacun de ces composants etant aussi 
represents par une action. 
15 Avec cette methode 10, le client definit les limites du probleme/processus pour 

lequel il souhaite mettre en oeuvre un logiciel executable sur mesure et ses relations 
avec Tenvironnement. II peut y introduire exactement ce que font les differentes 
personnes du centre de profit, les evenements exceptionnels prevus (par exemple 
les vacances de collaborateurs, les arrets d'une machine en maintenance), les aleas 
20 (par exemple une commande urgente ou une panne machine) dont il souhaite tenir 
compte et les criteres de decision d'alerte dont ils souhaitent disposer. 

Pour determiner la typologie indiquee ci-dessus. les operations repetitives 
realisees au cours du deroulement d'une application informatique ontete recensees : 

- ces operations sont identiques, quel que soit le sujet traite, 
25 - elies sont en nombre limite. 

- elles peuvent etre reparties en sept classes (classes "a" a "g", ci-dessus) 
Chacune des sept classes d'operations est traitee selon une approche 

orientSe « objet », en encapsulant les regies internes propres a la classe. regies de 
nature dSterminee repetitive, s'agissant du comportement d'objets informatiques (par 
30 opposition aux'objets des domaines applicatifs de gestion, soumis a I'aleatolre). Les 
caracteristiques propres d chaque classe. et necessaires pour faire fonctionner les 
regies internes, ont ete inventoriees et reunies dans des « structures » d*attributs, au 
sens informatique du terme « structure ». 
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Ainsi. dans une deuxieme etape, les diagrammes representant le derouiement 
du processus de gestion ou de pilotage sont saisis en mettant en oeuvre des ecrans 
de saisie qui guident Toperateur et lui interdisent de faire certaines saisies 
incorrectes ou incompletes. Chaque objet est dote d'attributs definlssant des 
5 donnees dans des formats predetermines (types de donnees. quantite, longueur et 
unite), des elements de stockage des donnees (dans des fichiers permanents et/ou 
avec une date de validite), des droits d'acces des differents utilisateurs et les 
interfaces qu'ils utiliseront, des elements de decision avec comparaison d'options 
(decision : acheter ou fabriquer, par exemple). Un support numerique permet de 
10 representer une application en remplissant les champs d'attributs dans les structures 
liees a chaque classe d'objet (par exemple. un ecran est totalement defini dans deux 
structures qui decrivent I'ensemble de Tecran et chaque champ de I'ecran). 
Le generateur 20 effectue les operations suivantes : 

- il verifie la syntaxe. 

15 - il verifie Texistence des informations necessaires, 

- il genere la base de donnees pour I'application, et 

- il compile I'executable pour fournir une application informatique sur mesure 
Le generateur 20 effectue une pre-compilation qui verifie que les attributs 

necessaires pour la logique de fonctionnement de Tapplication existent et sont 

20 convenablement remplis (en syntaxe et non en contenu). 

Chaque action est associ6e a une interface de saisie. Cette particularite est 
un des aspects de la presente invention. La compilation accomplit ensuite 
integration des descriptifs de donnees d'application et les assemble avec le logiciel 
systeme. pour obtenir un executable. Le logiciel systeme est permanent, commun a 

25 toutes les applications. 

L'automate 70 comporte un moteur 71 et met en oeuvre des fonctionnalites. 
Le moteur 71 repr6sente Tordre de mise en oeuvre des fonctionnalites et les 
procedures correspondant aux diagrammes de d6roulement de I'application 
informatique. Le moteur 71 relie chaque action d Tune de ses taches types 30 (il y en 

30 a une soixantai'ne) au moyen de mecanismes d'execution repartis en sept classes. 

Le moteur 71 possede un ensemble predetermine et permanent de taches 
programmees informatiquement, performantes et contr6l6es, appelees dans des 
actions applicatives. Ces actions sont ex6cutees par le coeur du moteur 71, suivant 
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un ordre defini dans des diagrammes organises sous forme d'arborescence, avec un 
mecanisme de controle du retour des taches conduisant a la poursuite du 
diagramme en cours, ou a un branchement vers un autre diagramme ou un autre 
sous processus. Par exemple, une tache de caicul se poursuit sur la tache suivante 
S dans le diagramme en cours, alors qu'une tache de comparaison conduit 
generalement a un branchement dSfini par la description de Taction appelant la tache 
de comparaisons. 

On observe que les descriptifs d'applications peuvent etre modifies ou 
completes : une nouvelle compilation foumit un executable a jour, compatible avec 

10 les autres versions, et evolutif. Cependant. si on change le descriptif d'un format de 
donnees, il faut transferer les donnees dans un nouveau fichier. avec le nouveau 
format, ceci grace a une procedure automatique appartenant aux composants 
proceduraux 40. En revanche, on peut ajouter des champs, dans la limite de la place 
disponible dans le fichier. ou etendre les dimensions du fichier avec la procedure 

1 S automatique evoquee ci-dessus. 

Grace a la mise en oeuvre de la pr6sente invention, on transforme une 
description proc^durale en executable sans la moindre ligne de langage 
informatique. Selon un de ses aspects, la presente invention definit un macro- 
langage et/ou une nouvelle couche systeme. 

20 On comprends alsement que, lorsque le client souhaite une modification, 

on modifie le schema du diagramme et, apres traitement. il obtient un nouvel 
executable sans qu'il soit necessaire de mettre en oeuvre des competences 
d'informaticien. 

Dans les logiciels connus. le deroulement des echanges entre le logiciel et les 
25 utilisateurs est conduit par le systeme graphique. Ici, c'est le logiciel qui a la maitrise 
du deroulement des operations, y compris avec le systeme graphique. On obtient 
ainsi Tindependance par rapport aux systemes externes, la possibilite de 
communiquer indiff^remment avec differentes interfaces, par identification de 
rinterlocuteur. 

30 Le moteur 71 execute les operations du processus d'une fapon neutre et 

independante du domaine d'application, grace d des mecanismes d'execution issus 
d'une typologie rigoureuse des modes de fonctionnement de Tinformatique et rSpartis 
en sept classes. 
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On observe que. dans la douzaine de structures utilisees (structure au sens 
informatique du terme), trois sont des structures dynamiques, une est une structure 
de navigation et les autres sont des structures descriptives de donnees. 

Des objets proceduraux applicatifs repetitifs et communs a tous types 
S d*application sont utilises : saisie de fiche simple, saisie de fiche avec liste attachee 
(par exemple les mouvements de stock pour un produit), impression, alerte. 
reconfiguration de fichiers de donnees. liaisons avec d'autres systemes d'information. 
S'y rattachent un mecanisme de deroulement et un superviseur qui constituent le 
"coeur" du moteur 71 . 

10 On va maintenant d§crire d'autres objets mis en oeuvre conformement a la 

presente invention. 
1/ Les donnees (ou "rubriques") 

- nom de la donnee 

- type alphanumerique, nombre 
15 - taille 

- cadrage 

- nombre de d6cimales et signe (si donnee num6rique) 

On observe qu'une rubrique est definie une seule fois pour une application et peut 
gtre appelee dans tout fichier ou interface de cette application. Une rubrique porte le 
20 meme nom dans toutes les applications, mais sa description est adaptee aux 
besoins de chaque applicatif : automatiquement les fichiers, interfaces et traitements 
disposent des specifications propres a I'application. 
21 Les fichiers de donnees (ou tables) 

- le nombre de donnees dans le fichier et la dimension de I'espace sur disque 
25 ou en memoire pour la gestion de chaque fiche, 

- la description des donnees de chaque enregistrement du fichier et leurs liens 
avec des donnees d'autres fichiers ou ecrans 

o nom de la rubrique, 
o liens avec d'autres fichiers ou ecrans 
30 3/ Les interfaces utilisateurs (^crans) 

- le nombre de donnees dans I'ecran et la dimension de I'espace de gestion de 
I'ecran 
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- la description de chaque donnee de Tecran fichier. de son comportement dans 
les echanges a travers I'interface homme-machine et ses liens avec des 
donnees d'autres fichiers ou 6crans : 

o nom de la rubrique, 

o liens avec d'autres fichiers ou ecrans, 

o type d'objet interface homme machine : libelle, texte, boutons radio, ... 
o positionnement sur Tecran, 

o mode de saisie : en mode creation de cle (mode d'acces au fichier, par 
example par nom ou par localisation) ou de selection, en mode courant 
(dans lequel on ne modifie plus de cle, sauf si elle est modifiable), 

o traitements lies a la donnee. en debut et en fin de saisie (a fin de 
controle. de traitements, ...), 

o champ sur lequel retourner en cas d'erreur 
4/ Les espaces de gestion dynamique des fichiers et ecrans, lors de leur utilisation 

- dimension des espaces, 

- valeur des donnees de la fiche ou de T^cran en cours d'usage (identification 
des donnees, quantit^s, montants, ...), 

- etats des traitements (phases de recherche d'une fiche. de traitements de la 
fiche, de validation de fiche), 

5/ Un navigateur, tra^ant pour chaque utilisateur, la route suivie au cours du 
deroulement de son travail et assistant une hyper-navigation par la possibilite 
d'atteindre directement des processus distants, puis de revenir au processus en 
cours : 

- etapes du parcours, 

- travaux realises au cours de Tetape. avec un tragage des liens avec les 
processus distants, assorti d'un mecanisme de retour automatique en arriere, 

6/ Des diagrammes de flux 

- description de diagrammes de traitements, avec des branchements soit 
choisis par Tutilisateur (par exemple par utilisation de menus), soit imposes 
par la logique du contexte (aiguillage sur deux processus differents de calcul 
d'un prix de revient suivant le caractere achetS ou fabrique d*un produit), 
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- sur chaque branche, appel a des actions de traitement : calcul, affectation de 
valeurs a des donnees, comparaisons. interface avec des fichiers ou des 
ecrans, ... 
7/ Des messages et menus 



- messages d'alerte, 

- choix de traitements par des menus 

D'une maniere gen6rale, la presente invention vise un systeme logiciel 
composite associant : 
10 1/ un moteur 71 capable de realiser de fagon standard et en temps reel : 

- des procedures de traitement d*informations de toutes natures, soit en 
simulation d'hypotheses futures, soit en mettant en oeuvre les evenements 
reels, 

- sous forme d'ensembles et sous-ensembles de traitements, coordonnes et 
15 possedant des capacites de boucles de feed-back fournissant et/ou 

echangeant des informations en retour, 

- avec la mise a disposition de tableaux de bord permanents et le 
declenchement de signaux d'alerte presentes instantanement ou en temps 
utile aux utilisateurs concernes (on definit done qui doit etre alerte et quand. 

20 dans le diagramme). 

21 un referentiel applicatif. cree a I'aide de la methode 10, decrivant les informations 
et leurs traitements specifiques et repondant exactement aux besoins de Tentreprise 
et des utilisateurs : 

pour un processus de gestion, ou un ensemble de processus en interrelation, 
25 - sous une forme de systeme et sous-systemes avec des boucles de feed-back, 

- avec une description sous forme banale et non informatique des flux r6els, si 
necessaire amenages pour plus de performances et de reactivite des acteurs 
et du systeme dans son ensemble. 

3/ un ggn^rateur 20 de logiciel executable sur mesure : 
30 - le logiciel executable est gSnerS sans programmation, en associant le moteur 
71 (paragraphe 1) et le referentiel (paragraphe 2) de Tapplicatif, 

- la description sur mesure des besoins exprimes dans le referentiel est traduite 
automatiquement dans le langage du moteur 71 
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- messages d' information, 
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- le generateur de logiciel executable est lui-meme construit avec le moteur 71 
standard avec son propre referentiel applicatif. 

D'une maniere plus detaillee. le moteur 71 est un ensemble de bibliotheques 
de fonctions C. java et Internet, perrhettant une gestion de processus, simples ou 
5 complexes, avec : 

- un traitement en temps reel des evenements et des informations qui leur sont 
liees, 

- la detection de situations anormales accompagnees d'un systeme de signaux 
d'alerte, 

10 - ridentification complete des evenements avec un stockage des donnees sous 
forme d'une base de connaissances a jour en permanence. 
Chaque bibliotheque est specialisee dans un domaine particulier, et liee aux 
autres dans un schema de relations fonctionnelles. Les fonctionnalites et donnees 
utilisees dans chaque bibliotheque sont formalisees dans un langage et avec une 
15 syntaxe propre au moteur 71 . 

La bibliotheque de gestion du deroulement des processus constitue 
I'automate 70 qui gere le deroulement des processus et ex6cute les operations qui 
les jalonnent. Le deroulement des operations est defini dans le referentiel applicatif, 
a Taide de la methode 10, en decrivant les flux reels, si necessaire amenages pour 
20 plus de performances et de reactivite, des la conception et facilement adaptables 
lorsque Torganisation change dans le temps. 

Les processus sont structures sous forme d'arborescences de flux 
operationnels. Ces arborescences repr6sentent les flux du reel, tels qu'ils ont ete 
analyses avec les utilisateurs a Taide de la methode 10. Le moteur 71 execute 
25 Tenchainement des operations sur chaque branche du flux en cours de traitement. 
Des branchements sont declenches : 

- soit par un choix de I'utilisateur a I'aide d'un menu, 

- soit par evaluation de la situation conditionnant les stapes suivantes : 

o choix d'une branche parmi plusieurs pour poursuivre le processus. 
30 o mise en oeuvre de signaux d'alerte et de boucles de feed-back 

(asservissement) 

Chaque processus est jalonnS d'opSrations ou actions. Le moteur 71 execute 
la suite de ces actions en faisant appei a une bibliotheque de taches. 
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Les taches utilisees, illustrees en figure 2. associees au deroulement des flux 
de la realite, sont de cinq types : 

a) taches complexes 21 d'appel a d'autres processus ou sous-processus. 

b) taches complexes d'aiguillage 22, 

5 c) taches simples 23 de calculs, de traitements d'informations. 

d) taches de communication et d'echanges 24 avec les utilisateurs. 

e) taches de transactions 25 avec des bases de donnees. 
Chacun de ces cinq types va etre decrit ci-dessous. 

a) Taches complexes 211 d'appel a d'autres processus ou sous-processus 
10 - ces taches lancent des applications, sous forme d'un nom de processus, 
chaque processus etant assorti de droits d'acces ; 

- chaque personne ayant un code d'acces regoit 

o Tattribution d'un processus initial par lequel elle entre dans le systeme, 
o une definition de ses droits qui guident ses acces a d'autres processus 
15 en cours de navigation, 

- les tdches d'appel a des processus permettent soit d'acceder a des 
« briques » fonctionnelles communes, soit de pratiquer une « hyper 
navigation » entre des fonctions et processus differents. 

o Le branchement sur un autre processus se termine par le retour 
20 automatique sur le processus en cours (hyper-navigation) 

- les « taches d'appel de processus » permettent de rendre tres simple et 
souple Tutilisation commune de processus et de declencher quatre types de 
processus : 

o un sous-processus 211 faisant suite au processus en cours. 
25 o un processus distant 212. 

o un sous-processus standard 213. commun a plusieurs processus, 
o un applicatif generique complexe 214, commun a toutes les 
transactions avec les utilisateurs 
Un sous-processus 211 se declenche d la suite d'un aiguillage issu d'un choix 
30 de Tutilisateur par utilisation d'un menu (le sous-processus a le nom du processus 
origine, complete du numSro du choix dans le menu) ou d'une evaluation de la 
situation (le r^ferentiel applicatif peut soit donner un nom spScifique au sous- 
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processus, soit conserver le nom du processus origine, en le completant d'une lettre 
(par exemple un « e » en cas de detection et de traitement d'une erreur). 

Par un processus distant 212. I'utilisateur evite un parcours difficile a travers 
des suites de menus. L'utilisateur accede directement a des taches annexes par une 
5 « hyper navigation ». Quand un processus distant 212 se termine, la navigation 
ram§ne au processus appelant. Ce mecanisme de processus distants permet de 
partager sans difficultes un processus entre plusieurs utilisateurs. services ou 
fonctions. Par exemple, la prise de commande peut se faire par un commercial 
eloigne ou proche, aussi bien que par un service d'administration des ventes local. 

10 Un sous processus standard 213 correspond ^ une procedure elementaire 

totalement repetitive et commune a plusieurs processus. Ces processus standards 
213 peuvent etre definis pour une entreprise. compte tenu de ses besoins 
particuliers. pour un ensemble d'entreprises, auxquelles s'imposent les memes 
logiques ou regies de base. Par exemple, un calcul de stock reel ou previsionnel 

15 peut etre realise au magasin, aux achats, dans un calcul automatique de sortie de 
stock, lors d'un ajustement d'inventaire. 

Un applicatif generique complexe 214 est commun A toutes les transactions 
r^alisees par les utilisateurs. II fait partie des fonctionnalites offertes par le procede 
objet de {'invention : 

20 - saisie simple, par exemple saisie ou mise d jour d'une fiche client, d'une fiche 
produit, 

- saisie de liste. par exemple saisie ou mise a jour d'une fiche nomenclature 
(liste des composants attach6s d une nomenclature). 

- declenchement d'alerte dans les processus de pilotage, par exemple 
25 depassement de delai, ecart anormal entre budget previsionnel et realise, 

- impression, par exemple. impression de certaines donnees clients : un client, 
une categorie de clients, la totalite du fichier client (liste des clients avec leurs 
adresses, ou leurs chiffres d'affaires, leurs commandes en cours, ...). 
Taches complexes d'aiguillage 22. A chaque noeud de Tarborescence. les 

30 aiguillages entre plusieurs branchements sont d^clenches par trois voies : un choix 
221 de I'utilisateur. par une navigation avec un menu, une identification d'une 
situation precise 222 comportant plusieurs possibilites de traitement (par exemple, 
dans le calcul de prix de revient d'un produit d partir de sa nomenclature, les calculs 
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du cout d'un produit achate et celui d*un produit fabrique sont differents et donnent 
lieu a des sous-processus differents), une evaluation d'une situation 223 sur la base 
de criteres de controle avec declenchement d'alertes, de boucles de feed-back (par 
exemple couts ou delais anormaux). 
5 Les taches simples 23 de calculs ou de traitements dinformation se 

caracterisent par le fait qu'elles seules traitent directement les informations. Le 
procede de Tinvention inclut les informations utiles a la conduite et a la maTtrise des 
flux et pr6voit le pilotage et Taide ^ la decision operationnelle. Le dispositif utilise des 
capteurs et des regies de controle au plus pres des evenements. Le processus 

10 recueille les informations des qu'un evenement survient, en temps reel, et declenche 
en tant que de besoin des signaux d'alerte aupres des personnes chargees des 
decisions operationnelles, dans les delais utiles (definis par le diagramme) pour 
chacune d'elles (immediat pour les decisions d'execution. ou avec un delai approprie 
a la bonne efficacite des decisions de gestion). 

15 Les calculs 231 comportent les operations de base, avec prise en compte du 

nombre de d6cimales, les cumuls et ventilations et Tattribution de valeurs 
alphabetiques ou numeriques. 

Les comparaisons 232 sont effectuees entre des donnees alphabetiques ou 
numeriques. D'apres le resultat d'une comparaison, on declenche des branches de 

20 traitement appropriees. 

Uenvoi de message 233 est effectue vers Tutilisateur ou vers d'autres 
utilisateurs (alerte), en fonction de resultats constates d un poste. 

Les transferts 234 sont relatifs a des liens entre des champs d'un ecran ou 
d'un fichier avec des champs d'autres ecrans ou fichiers, soit en importation, soit en 

25 exportation. Un transfert ponctuel peut aussi etre effectue entre des champs d*origine 
et des champs de destination. 

Le traitement de dates 235 concerne Tattribution de la date et de Theure 
« systeme ». le calcul de dates de debut et de fin d'operations d'apres un delai ou 
calcul d'un d^lal d'apres des dates de debut et de fin, et la comparaison de dates. 

30 Les taches de communication et d'echange 24 avec les utilisateurs se font par 

rinterm6diaire d'un terminal informatique, soit a travers un reseau classique, soit par 
un navigateur internet. Le moteur 71 comporte un superviseur charge de reconnaTtre 
la configuration materielle et de communication (reseau local, intranet, internet, ...) 
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de Tutilisateur, et il est done inutile de generer celle-ci dans I'applicatif. La gestion 
des echanges se fait par des taches sur Tensemble d'un ecran. sur certains champs 
ou par des messages envoyes a Tutilisateur par le deroulement du processus. 

Les taches de communication et d'6change 24 comportent : 
5 - la creation et destruction d'un ecran (activation de I'ecran et affectation de 

memoire) 241, 

- Taffichage d'une page complete 242, avec son titre, ses libelles et ses champs 
d'information puis effacement de la page, 

- Taffichage d 'informations dans des champs 243 et modification d'ecran, y 
10 compris affichage de Tensemble des informations (par exemple a la lecture 

d'une fiche). I'affichage de champs modifies (par exemple a la suite de calculs 
d6clenches par la saisie d*un champ et influengant d'autres champs, 
attribution de valeur dans un bouton radio. ...) 

- la gestion des autorisations de modification 244, sur les constituant des codes 
15 ou noms servant ^ lire des fiches sur la base de donnees (acces en mode de 

selection, champs de des modifiables ou non), ou sur les informations 
courantes de la page d'ecran (acces en mode de mise a jour, acces en simple 
consultation ou champ sans objet contextuel), 

- le positionnement particulier sur un champ 245, y compris champ obligatoire a 
20 remplir et champs a corriger en cas d'erreur de saisie reconnue, 

- renvoi de message 246, y compris information a Tutilisateur, en particulier en 
cas d'erreur, I'affichage d'une boTte de dialogue a acquitter avant reprise de la 
saisie d'ecran, ou I'affichage d'un message d'information durable en bas de 
I'ecran. 

25 - I'effacement de I'ecran 247. y compris passage provisoire a un autre ecran et, 
en fin d'utilisation d'un ecran, avant sa destruction. 

On observe que le dessin des ecrans est adapte a chaque categorie 
d'utilisateurs, en fonction des besoins de chacun. Leur simple description dans le 
r6f6rentiel applicatif suffit a faire fonctionner les taches de gestion des echanges 
30 indiqu^s ci-dessus. II est facile et rapide de les adapter en tant que de besoin, par 
simple modification de leur descriptif. Les informations sont presentees sous forme 
d'objets graphiques et sp^cifiees comme telles (champ de saisie ordinaire, boutons 
« base de donnees », boutons radio verticaux ou horizontaux, cases a cocher. 
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languettes. editeur, table, code a barres. libelle. lien hypertexte). Les champs 
d'informations sont accessibles en mise a jour, accessibles seulement en 
consultation ou invisibles a destination par exemple de champs d'identificateurs, de 
champs intermediaires de calculs, ou de champs d'informations elaborees a 
5 destination de tableaux de bord distants. 

Concernant les droits d'acces, tout acces aux processus est soumis a un 
contrdle des droits de la personne en ligne. Chaque personne accedant a I'applicatif 
ne peut « voir », modifier, que ce qui lui est attribue par les droits qu'elle a regu avec 
son code d'acces. Ces droits peuvent changer dans le temps, sous la responsabilite 
10 d*un gestionnaire des acces. Une personne ayant des droits eleves a interet a 
recevoir plusieurs codes d'acces avec des droits de plusieurs niveaux, afin de limiter 
les risques d'acces intempestifs, par d*autres personnes. a des informations 
confidentielles. 

La presentation des documents imprimes est consideree comme celle d'un 
IS ecran. avec la limite d'un acces a consultation, avec la possibilite de disposer de 
dimensions de « pages » plus grandes. 

Les taches de transaction avec des bases de donnees 25 comportent : 

- rinitialisation et la liberation des espaces d'informations lies d un fichier 251 . 

- la creation ou la mise a jour de fiches 252 par 6criture sur la base destinataire 
20 (chaque fiche regoit automatiquement un numero d'identification univoque qui 

sert de iien entre des items apparentes, sans que des modifications de code 
ou d'appellation aient une quelconque cons6quence, 

- la creation de des d'acces pour lecture de fiche particuliere 253 : acces 
possible par des codes, des noms, des periodes de validite, des liens avec 

25 d'autres fiches. ... (I'acces a la base de donnees en multi-codification permet 

de rendre les informations accessibles a chaque categorie d'utilisateurs en 
respectant sa culture propre, par exemple les codes produits sont souvent 
differents pour la technique et pour le commercial, voire entre plusieurs 
6tablissements; entre plusieurs processus autonomes (exemple : liaisons 

30 entre les differents services fournis par une banque ^ un meme client). 

- la lecture d'une fiche 254 (la fiche est lue sur une ou plusieurs cles d'acc6s d 
preciser : code, nom, identificateur, ... 
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- la lecture d'une liste de fiches ayant un rattachement commun 255 (par 
exemple les mouvements de stocks rattaches a un produit, composants d'un 
produit, lignes de commande, liste des commandes en cours pour un client, 
liste des commandes pour un produit), 

5 - la suppression d'une fiche 256, selon des modalites de controle 
predetermin§es (par exemple, ne pas supprimer une fiche produit si elle 
possede un stock ou si une ligne de commande en cours y est rattachee), 

- le parcours d'un fichier pour operer un traitement systematique sur toutes les 
fiches, sur un ensemble de fiches entre deux homes, ou sur des fiches ayant 

10 une meme racine (par exemple, impression de tout ou partie d'un fichier. 

valorisation de marges sur toutes les commandes d'un meme client, d'un 
agent commercial, d'une region, ... 

Le moteur 71 gere la ou les bases de donnees d'apres le descriptif des 
fichiers de donnees fourni par le referentiel applicatif, c'est-a-dire la liste des 

15 informations contenues dans chaque fiche et la liste des index d'acces. avec la liste 
des champs servant a constituer chacun de ces index, les liens entre des 
codifications multiples d'un meme item dans plusieurs services (commercial et 
technique), plusieurs sites ou plusieurs entreprises (clients - fournisseurs, societes 
fusionnees, ...), les bases de donnees etant alors synchronisees selon une 

20 frequence d6terminee par le diagramme ou a la demande ou avant certains 
evenements (par exemple pour realiser un devis client). 

On observe, concernant revolution du referentiel applicatif dans le temps, que, 
dans certaines limites de dimensions de chaque fiche. controlees par le moteur 71, il 
est possible de completer les informations contenues dans un fichier. Si les formats 

25 des informations utilisees dans I'entreprise se modifient dans le temps, il est aise de 
maintenir les donnees acquises dans le passe par une procedure systeme du moteur 
71. 

La bibliotheque de liaison 26 est partagee entre le referentiel applicatif et le 
moteur 71. Les informations necessaires a I'execution des taches doivent etre 
30 sp6cifiees en tant que de besoin et le moteur 71 les rattache a sept types : 

a) menus et choix 261, 

b) messages et alertes 262, 

c) champs d'information et format de donnees 263, 
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d) designations des informations 264, 

e) fichiers265, 

f) interfaces visuelles 266, ecrans ou pages internet. 

g) branches de processus et taches 267. 

5 Les nnenus et choix 261. Les taches d'aiguillage declenchees par les 

utilisateurs comportent des informations de type « menus et choix ». Les utilisateurs 
se voient proposer un menu a chaque fois que leur intervention est necessaire pour 
choisir entre plusieurs sous-processus et poursuivre la navigation. Le precede 
nomme « choix » chacun des elements du menu. A chaque choix est lie une branche 
10 du processus. Chacune des branches est dotee d'un code d'accds : si Tutilisateur ne 
possede pas les droits necessaires, le menu filtre et ne propose par le choix 
correspondant.. 

Les messages et alertes 262. Le precede nomme « messages » les echanges 
declenches au cours de transactions avec un utilisateur. Le precede envoie, 

15 exclusivement a I'utilisateur, des messages d'information pour faciliter sa tache et 
des messages d'anomalie et d'erreur lorsque celles-ci sont detectees. Le precede 
nomme « alerte » renvoi d'inforrnations de pilotage a teus les utilisateurs concernes 
lorsqu'il detecte des anomalies, au cours d'un processus. Les alertes, envoyees a 
distance, sont d'une autre nature que les messages et sont rattachees a la 

20 procedure standard de gestion des alertes. Les tSches d'echanges et de 
communication avec les utilisateurs se font en temps reel. 

Les champs d'information 263. Chaque element d'une liste d'informations 
dans un fichier et dans une interface visuelle est nomme un « champ ». Pour les 
champs d'un fichier, la specification du format de chaque information indique la taiile 

25 de I'information et reserve en consequence la place necessaire pour les stecker sur 
disque. Lors de la generation du legiciel, la base de dennees est automatiquement 
creee ou mise a jour. Pour les champs d'un ecran, d'une page internet ou d'un 
imprime. leur presentation peut etre faite suivant la demande de I'utilisateur et 
changee aisement. 

30 Chaque' champ possede un nom et un formaL Chaque entreprise utilise un 

ensemble de donnSes de base : references techniques et commerciales des 
produits, prix unitaires, montant d'une facture, temps, couts, delais d'une commande, 
chiffre d'affaire hers taxes et toutes taxes comprises, ... 
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Le precede nomme « format des donnees ». la specification du format de 
chacune de ces donnees. Ce format des donnees est utilise pour reserver la place 
necessatre dans les fichiers, pour afficher correctement les informations et pour 
contrdler la saisie des informations. L*attribution d*un format a une information 
5 specifie sa presentation et sa dimension : type attribue (donnee alphanumerique. 
code numerique. nombre. date. ...). description (nombre de caractere. cadrage. 
presence eventuelle d'un signe, nombre de chiffres de la partie entiere et nombre de 
decimates, numero du mois inferieur ou egale a 12, numero de la semaine inferieur 
ou 6gal a 54, jour dans le mois inferieur ou 6gal a 31, heure inferieure ou egale a 24. 
10 ... 

Le proced6 g6re une codification multiple (multi-codification) pour tenir compte 
de references differentes pour un meme objet. par exemple references techniques et 
commerciales, liens entre processus distincts, references differentes entre plusieurs 
sites ou societes appartenant au meme groupe, ou plusieurs entreprises liees 

15 economiquement (clients - fournisseurs. societes fusionnees, ...). 

Designation des informations 264. Le proced6 identifie par une designation les 
informations presentees sur les supports de communication avec les utilisateurs. 
Chaque information d'une interface est presentee avec une designation. Plusieurs 
d§signations peuvent dtre utilisees pour tenir compte des differences de langue ou 

20 de fonction des utilisateurs. 

Fichiers 265. Le precede definit la structure des informations dans les fichiers 
et Torganisation de leur stockage en base de donnees. Les fichiers recueillent des 
ensembles d 'informations structur6es. Une fiche est une structure de fichier (par 
exemple fiche-client) comporte une liste d'informations definies par un nom et un 

25 format. Chaque fiche d'un fichier peut etre atteinte par plusieurs cles d'acces 
differentes suivant la preoccupation de Tutilisateur. ou son besoin immediat. Les 
6venements sont identifies en temps reel avec des etiquettes appropriees a la 
situation vecue. La base de donnees constitue une base de connaissances en 
permanence ^ jour. 

30 Interfaces visuelles 266. ecrans ou pages internet. Le precede definit 

{'organisation des informations pour leur presentation aux utilisateurs. Les interfaces 
visuelles representent un ensemble d'informations qui sont affichees avec leur 
designation sur un 6cran d'ordinateur, une page internet, un imprim6. Comme pour 
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les fichiers. une interface visuelle comporta une liste d'informations definies par un 
nom et un format, ainsi qu'un Jien avec les donnees correspondantes stockees dans 
les fichiers. Chaque information est dotee d'attributs precisant leur presentation 
visuelle. leur mode de traitement ou de saisie. Les interfaces visuelles peuvent etre 
5 presentees sous une forme appropriee a chaque utilisateur, et modifiees pour 
r^pondre a de nouveaux utilisateurs ou de nouveaux besoins. 

Branches de processus et tdches 267. Chaque branche de processus est 
representee dans un diagramme et reflete la description des flux reels, obtenue avec 
le referentiel applicatif : nom du processus, enchainement des operations, noeuds de 

10 branchements, droits d'acces au processus (services, postes agr66s). Chacune des 
operations doit etre decrite : nom de ('operation, nom de la tache du moteur 71 qui 
devra etre executee, parametres de Toperation. suivant la syntaxe determinee pour 
chacune des taches existantes. 
Le referentiel applicatif. 

15 Ce referentiel est cree en association avec les utilisateurs concernes par le 

processus a informatiser, d'apres la situation existante. et en etudiant d'eventuelles 
ameliorations, facilitees par Temploi d'un outil informatique. Une fois Taccord des 
utilisateurs obtenu, le referentiel est numSrise (par exemple, par saisie ou par lecture 
optique ou sonore). en vue d'obtenir une importation automatique dans ie logiciel 

20 executable. 

Gen6rateur de logiciel executable sur mesure 20. Ce gen6rateur utilise les 
donnees du referentiel applicatif, transcrites sous forme numerique. Le generateur 20 
precede en deux etapes : 

- importation 361 (voir figure 3) des donnees du referentiel dans une base de 
25 donnees interne, et 

- generation 362 (voir figure 3) du logiciel executable. 

On observe, en figure 3, que la mise en oeuvre d'un mode particulier de 
realisation du precede objet de la presente invention comporte le mise en oeuvre 
d'un logiciel systeme commun d tous les logiciels applicatifs et : 
30 - une etape*d*inittalisation 31 d'un systeme informatique, 

- une etape de representation 32 du processus, mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets generiques, typiquement inferieur ^ vingt, 
dans au moins un diagramme de rappllcation, 
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- une etape de transcription 33 de chaque objet de chaque diagramme en une 
action correspondant a un objet dote d'attributs. chaque classe d'action ou objet 
gen^rique etant associe a une Interface de saisie de donnees d'application. 
comportant. pour programmer chaque action : 

5 i) une etape de nommage 331 au cours de laquelle on donne un nom a ladite 

action, 

ii) une etape de definition de fonction 332. au cours de laquelle on met ladite 
action en correspondance avec une t§che, et, 

iii) une etape de definition dinformation 333. au cours de laquelle on designe 
10 les informations qui seront traitees dans Taction. 

- une etape de transcription 34 des noeuds, embranchements et feuilles de 
chaque diagramme en une action correspondant a un objet dote d^attributs. 

- une etape de pre-compilation 35 au cours de laquelle on verifie que les attributs 
des objets necessaires pour la logique de fonctionnement de Tapplication existent 

15 et sont convenablement fournis. en syntaxe, 

- une etape de compilation 36 au cours de laquelle les descriptifs de donnees des 
objets dotes d'attributs sont integres et sont assembles avec le logiciel systeme. 
pour obtenir un logiciel applicatif executable, et 

- une etape d'execution 37 du logiciel applicatif executable compile au cours de 
20 rstape de compilation 36. 

Au cours de I'etape de transcription d'objets, une ou plusieurs action(s) 
lance(nt) un traitement complet se trouvant a un endroit distant d'une arborescence 
correspondant audit au moins un diagramme. et une fois celui-ci termine. retourne a 
son point de depart. 

25 Preferentiellement. au cours de Tetape d'execution. le logiciel applicatif 

executable met en oeuvre une bibliotheque de gestion du deroulement des 
processus correspondant audit au moins un diagramme, ladite bibliotheque 
constituent un automate 70 qui gere le deroulement des processus et execute les 
operations qui les jalonnent, le deroulement des operations 6tant defini. dans le 

30 ref^rentiel applicatif. a I'aide de la m^thode 10, en decrivant les flux r^els. 

Preferentiellement. au cours de I'etape de compilation ou au cours de I'etape 
d'execution, 11 met en oeuvre le moteur 71 qui comporte un superviseur charge de 
reconnaitre la configuration mat6rielle et de communication. Pr6f6rentiellement, le 



wo 03/085521 




iPCT/FR03/01019 



moteur 71 gere une ou plusieurs bases de donnees d'apres un deschptif des fichiers 
de donnees fourni par le referential applicatif, c'est-a-dire une liste des informations 
contenues dans chaque fiche et la liste des index d'acces, avec une liste des 
champs servant a constituer chacun de ces index, les liens entre des codifications 
5 multiples d'un meme item dans plusieurs services, plusieurs sites ou plusieurs 
entreprises. Les bases de donnees sont synchronisees selon une frequence 
determinee par le diagramme, a la demande ou avant certains evenements 
predetermines. 

Pr6f6rentiellement. I'etape de compilation (36) remplace le nom d'action donne 
10 par le transcripteur, au cours de Tetape 33, par un index dans une table de taches. 

Preferentiellement, au cours des etapes de representation et de transcription, 
ledit au moins un diagramme correspond a au moins une arborescence dans laquelle 
les nceuds et feuilles. ou le code est effectue, sont composes d'actions. les valeurs 
de retour de ces actions determinant le deplacement dans Tarborescence. 
15 Une fois terminee la generation, le precede peut passer sur Tappiicatif de 

Tentreprise, chaque processus de Tentreprise 6tant accessible suivant les droits des 
utilisateurs. 

Le referentiel applicatif peut etre modifie. Une nouvelle generation du logiciel 
executable met a la disposition des utilisateurs la nouvelle version. Le temps 
20 necessaire a une generation est de Tordre de dix a trente minutes, suivant 
■'importance du processus. 

Etape d'importation 361 des donnees du referentiel dans une base de 
donnees interne. Au cours de cette phase, le generateur 20 controle la synthaxe et la 
coherence des donnees fournies par le descriptif de {'application. La presence de 
25 certaines donnees de description obligatoires est controlee. Les donnees appelees 
dans les traitements doivent exister : champs d'informations, libelles, messages, 
processus, taches. Si le generateur 20 detecte une erreur, il envoie un message et 
refuse de passer a la phase suivante. 

Etape de generation 362. Une fois le referentiel applicatif accepte, le 
30 generateur 20 gen^re le logiciel applicatif en associant le moteur 71 et les donnees 
applicatives. La fin de cette phase de generation 362 redonne la main d Tutilisateur. 
avec la nouvelle version disponible en cas de changements. 
On definit deux classes de structures : 
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- celles qui servent a decrire les informations utilisees dans les applications, 
particulierement le format des donnees, la structure des enregistrements dans 
la base de donnees et la fagon dont les ecrans sont presentes. et 

- celles qui correspondent a la fafon dont le programme va se derouler (I'ordre 
5 dans lequel les traitements vont etre effectu6s) : diagramme de flux ou de 

processus et actions sur les flux. 

Les premieres sont des donnees de description et les secondes des donnees 
de deroulement. 

Les donnees de deroulement comportent : 
10 a/ les actions 

Les donnees de deroulement ont une organisation particuliere qui a une forte 
incidence sur la fagon de programmer les applications, Une des motivations est 
d'eviter la programmation directe en langage informatique. par exemple en langage 
C. A cet effet. un certain nombre de fonctions de manipulation et de presentation des 
15 donn§es ont ete definles. Leur ont ete associees un certain nombre d'arguments. 
fixes ou pouvant etre parametres grace a certaines structures de donnees (les 
« cartes » decrites plus loin) et d'empaqueter le tout dans un ensemble identlfie par 
un code. Chaque ensemble porte le nom d' « action ». La structure action est donnee 
ci-dessous : 
20 struct action 

{ 

char *ac_name; 
int *ac_fonc 
unsigned long ac_param[MPRMl; 
25 char *ac_article; 

} 

Programmer une action, dans cet esprit, revient simplement a lui donner un 
nom, affecter la "tache moteur" ou "tache type" (par exemple : calcul, comparaison. 
controle, branchements. ...) et designer les informations qui seront traitees dans 
30 Taction. 

Les actions sont enchalnees suivant leur ordre fonctionnel dans des 
diagrammes. Les actions ramenant toutes a des codes definis. il est possible de 
representer ainsi les structures de controle classiques telles que branchement. 
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boucle, test, etc ... Ces controles sont eux-memes effectues par des actions, voir 
plus loin. Deroulement du code dans Tapplication - Diagrammes de processus. 

Le concept sur lequel le deroulement est base, intimement lie a celui d'action. 
est celui d'arborescence. Ce n'est pas une idee nouvelle qu'une application a base 
5 de menus soit structuree en forme d'arborescence. Dans notre cas cependant. le 
diagramme a ceci de particulier que ses noeuds et feuilles. ou le code est effectue, 
sont composes d'actions. En fait, chaque noeud est un receptacle ou peuvent tenir 
MACT actions - Le nombre d'actions dans une branche, MACT. est un parametre du 
moteur 71. Les valeurs de retour fournies par ces actions, determinent le 
10 deplacement dans les arborescences. 

On observe qu'assembler un certain nombre d'actions standards en des 
diagrammes donne un resultat plus simple a controler que du code C genere 
directement. Le principe etant que des actions, supposees travailler sur des donnees 
convenablement encapsulees. sont considerees comme sures, et leur contenu n'a 
15 jamais a etre trace. 

implementation des diagrammes. 

Les noms des diagrammes et les actions jalonnant les diagrammes sont 
places dans une structure appelee struct branche. La structure branche est d^crite 
ci-dessous : 
20 typedef struct branche 

{ 

char nom_digramme[LNOM]; 
unsigned int table_traitements[MACT]; 
char *securite ; 

25 } node; 

Le nom "nom_diagramme" permet d'identifier le diagramme et de se deplacer 
de diagramme en diagramme. Les elements de table_traitements sont des actions 
qui seront ex^cutees a Tarrivee sur le diagramme; le concepteur leur donne un nom 
et la compilation remplace ces noms par des index des actions dans une table qui 
30 les regroupe : feur acc6s est instantan6 et permet d'obtenir de bonnes performances 
des traitements informatiques. 

La chaTne de caract&res "securite" est examinee avant toute demande 
d*arriv§e sur le diagramme, pour permettre d'interdire I'acces en fonction des droits 
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de Tutilisateur de Tapplication. C'est ainsi que certains menus ne seront pas visibles 
pour certains utilisateurs, et visibles pour d'autres. 

On decrit ci-dessous, sur un exemple. la fagon dont on se deplace dans les 
noeuds et dont on execute le code. 
5 Supposons que le nom du diagramme courant soit « L », 

En arrivant sur ce diagramme, le syst^me execute Taction tab_tr[0]. Si elle 
ramene le code NEXT, comme le font, par exemple les 4 premieres actions du 
diagramme L11, on execute Taction suivante. Si elle ramene DSCD (pour 
« descend »). elle doit aussi avoir positionn6 une variable globale, Choix. Cette 

10 variable va aiors etre concatenee au nom du diagramme courant, pour donner le 
nom du nouveau diagramme. Par exemple. si la variable choix vaut « 1 ». on se 
dirige vers le diagramme « L1 ». On note DSCD(1) Tassociation de DSCD et de 
choix=1. L'inverse de la procedure se produit si une action retourne RMTE. Dans ce 
cas, Taction doit avoir positionne certains drapeaux (« flags ») internes pour 

15 determiner a quelle action de la branche de remontee on reprend le traitement. Par 
exemple. une remontee a Taction 3 depuis L1 nous positionne sur la quatrl§me 
action du noeud L (les actions etant numerotees d partir de 0.) 

Plus precisement, c'est le caract6re ASCII representant le nombre choisi qui 
est additionne. II faut done 6viter de donner d "Choix" une valeur en dehors de 

20 Tintervalle (a-2A-Z-0-91. afin d'eviter les caracteres invisibles ou dotes de 
fonctionnalites dans la table ASCII. 

On peut enfin passer a une action du meme noeud sans que ce soit 
necessairement la suivante en positionnant NACT plus le numero d'ordre de Taction 
a atteindre par la branche Choix et en retournant NACT. Le traitement se poursuit 

25 tant que Ton n'est pas passe sur une action de sortie, dont la fonction associee est 
de fermer les fichiers restes ouverts dans la base de donnees et de liberer les 
espaces memoires. 

On observe que cela ne signifie pas forcement que I'on est revenu a la racine 
ou que Ton a parcouru tout le diagramme ou toute autre condition de cet ordre. II est 
30 aussi possible de sortir « en urgence » de Tapplication .avec certaines routines de 
traitement d'erreurs qui envoient un message et ferment ou cidturent la session. 

On comprend que le systeme, lors du passage dans les menus, interprete les 
entrees clavier. Si une touche de fonction (de F1 d F9 dans la version standard) est 
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tapee. on descend immediatement sur la branche courante, a laquelle on concatene 
un caractere entre « 1 » et « 9 ». n peut ainsi tracer le chemin parcouru depuis le 
debut. II existe par ailleurs une variable globale de debuggage, qui affiche, tors des 
parcours des diagrammes, le nom dd la branche courante en bas d'ecran et permet 
5 de controler le bon deroulement de la procedure et d'identifier rapidement les erreurs 
commises dans la numerisation des processus. 

Cependant, si une action positionne, par exennple, Choix a « 7 ». rien ne 
permet de savoir, d la lecture des sources du diagramme, si la branche obtenue est 
atteinte suite a une entree clavier, ou suite a un traitement. On conseille au 
10 concepteur de reserver des valeurs de Choix menu dans Tintervalle [1-9] aux 
branchements obtenus dans un menu, et d^affecter des valeurs alphabetique pour les 
branchements declenches autbmatiquement par le contexe applicatif. 

On note que si la derniere action d'un diagramme ramene la valeur NEXT, le 
systeme trouve une erreur et s'arrete, de meme que si on cherche a descendre 
15 lorsque Ton se trouve deja sur une feuille. ou si on cherche a remonter en etant deja 
a la racine. 

Lancement des diagrammes. 

Le nom du premier diagramme lance depend de I'activitS desiree. II est lanc§ 
a la fin du main par un appel ^ la fonction d'interpretatton de diagramme. Cette 

20 routine prend bien sQr le nom du diagramme en argument, mais aussi le numero de 
Taction qui est executee en premier. En effet, on veut parfois 6viter de debuter a 
Taction 0, les premieres actions pouvant par exemple effectuer des initialisations 
indesirables. On donne aussi les arguments type_arbre et no_arbre qui donneront 
leurs valeurs aux variables tp_arb et no_arb, Ces variables permettent de determiner 

25 le type de diagramme. c*est-a-dire s'il s'agit d'un diagramme de Saisie. de Liste ou 
d'Impression, pour parler des types standards, ou un autre type si besoin est. 
Comme plusieurs modules peuvent avoir le meme type (par exemple, les modules 
clients, fournisseurs et articles peuvent etre tous des Saisies), on les distingue par un 
num6ro d'ordre no_arb. Ce num6ro depend de la generation des cartes par le 

30 generateur 3/ Ces variables permettent de relier les tables de parametres 
personnalis6s d'un module a un processus commun standard (voir saisies de fiches 
simples ou de fiches de listes, impression. d6clenchements d'alerte). 
Lancement de diagrammes partictiliers 
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II est parfois interessant, depuis une action donnee, de lancer un traitement 
complet se trouvant a un endroit distant de Tarborescence. et une fois celui-ci fini, de 
se retrouver a son point de depart. Cela est rendu possible par le fait que. bien que 
tous les diagrammes de Tapplication soient regroupes dans un meme tableau, celui- 
5 ci regroupe en fait une foret. On peut lancer une arborescence nouvelle comme un 
lien avec un « sous-processus » ou "sous-systeme" en terme cybernetique, a Taide 
de Taction de lancement d'un diagramme, tout comme « main() » lance le 
diagramme initial. C'est meme ainsi que les divers modules sont integres a 
rapplication. On utilise un diagramme existant decrivant un module, on lui donne un 
10 nom, et, depuis notre arborescence d'origine, on lance le diagramme en question. 
On sort de ce diagramme particulier par une action ramenant ENDA. 

Diagrammes clients et diagrammes communs 

Les diagrammes clients sont des diagrammes specifiques a une application. 
Les diagrammes communs sont des « objets proceduraux », permanents et 
15 accessibles par Tappel a des cartes tdentifiant les travaux a realiser et les 
informations necessaires pour obtenir le deroulement d'une procedure specifique 
suivant un modele standard (objet procedural) : nom des fichiers et ecrans, noms 
des menus et messages, diagrammes de traitement ^ executer a des moments 
precis de la procedure (par exemple : fin de la selection d'une fiche a mettre a jour). 
20 Certains ensembles de traitements vont etre utilises dans toutes les applications. Par 
exemple, les processus de saisie de liste. de Saisies, d'impressions, etc ... sont 
communs. Dans le cas des Saisies. par exemple, on a toujours un menu proposant 
un choix de type : 

CREATION 
25 MISEAJOUR 

CONSULTATION 

SUPPRESSION 

FIN 

puis, apres selection de MISE A JOUR, on a un choix, par exemple : 
30 PREMIER 
DERNIER 
SELECTION 
FIN 
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puis, apres selection de PREMIER, parexemple : 
PREMIER 
DERNIER 
SUIVANT 
5 PRECEDENT 
SELECTION 
VALIDATION CHOIX 
FIN. 

Les d6roulements de ces diagrammes sont fixes de fa?on permanente dans 

10 des procedures standard. II suffit de fournir les identificateurs d'ecrans et de fichiers 
utilises, et ces diagrammes vont les visualiser, modifier les menus au fur et d mesure 
des etapes. etc ... Le mecanrsme de la procedure est toujours identique, mais son 
contenu est adapte, sur mesure, aux besoins exprimes par les utilisateurs. Bien 
entendu. un certain nombre de points d'entree subsiste pour inserer des actions 

15 particuli6res a chaque client, par exemple si le mode de lecture des donnees est tres 
particulier (par exemple, si le fichier n'est pas un fichier standard mais est importe 
d'un autre systeme, la fagon de lire la premiere fiche n'est pas standard, done doit 
etre donnee par le concepteur). Par contre, le fait d'avoir le choix de demander la 
premiere fiche reste standard, done le diagramme considere est utilisable. 

20 L'ensemble des informations propres S chacun des applicatifs est reuni de fa9on 
structur6e dans des "cartes" (voir ci-apr§s) : le concepteur "cable" une carte pour 
approprier le processus standard a chaque processus particulier 

Les traitements particuliers a certains clients qui ne sont pas generalisables 
sont codes sous forme de diagrammes specifiques et d'actions. Ceux-ci ont 

25 exactement la meme structure que les diagrammes standards, mais sont places 
dans un tableau secondaire, done ne sont pas compiles avec les applications n'y 
acc§dant pas. Notons que la recherche des noms diagrammes par le systeme 
commence toujours par les diagrammes clients, il est ainsi possible de definir son 
propre diagramme client et de lui donner le m§me nom qu'un diagramme commun 

30 dont on n'apprecie pas le comportement. C'est le diagramme client qui sera pris d la 
place. On ne peut, en revanche, demander explicitement d utiliser la version client ou 
la version commune d'un diagramme. 

Lancement d'actions supplementaires 



wo 03/085521 




|PCT/FR03/01019 



Parfois. le nombre d'actions maximal d'un diagramme n'est pas suffisaiit pour 
effectuer un traitement. II existe plusieurs methodes pour regler ce type de 
problemes. On peut aussi lancer une action particuliere qui permet de se rebrancher 
sur un diagramme avec un retour a Taction sulvant Taction de branchement 
5 (hypernavigation). 

Sur chaque champ d'ecran, on peut d6clencher des diagrammes, a Tentree du 
champ et d la sortie (attribution de valeurs. calculs instantan6s, ...) 

Cartes 

Les cartes sont des ensembles de parametres permettant d'orchestrer le 
10 comportement des diagrammes qui lui sont relatifs. Elles regroupent la plupart des 
informations utiles pour la gestion des divers modules constitutifs d'une application, 
par exemple le nom des fichiers concernes, des ecrans de Saisie. d*en-tete et de 
liste si besoin est, les noms des champs de cle pour les lectures/ecritures de 
donnees, des drapeaux (flags) de controle de traitements, les noms des menus a 
15 afficher en bas des ecrans, les actions specifiques a lancer dans le deroulement des 
diagrammes, etc ... 

Une carte est une structure regroupant un certain nombre d'entrees 
numeriques non signees, et un certain nombre de chaines de caracteres. Nous ne 
considerons que le cas des donnees num6riques, la discussion etant similaire pour 
20 les cartes concernant des donnees de type « caract6re ». 

On distingue, en general trois types de cartes, correspondant aux trois grands 
types de traitement. les cartes de Saisies. les cartes de Listes et les cartes 
d'impression. La difference entre chaque type reside seulement dans le nombre et la 
signification des entrees de la structure le representant. 
25 Uidentification de ces cartes est donnee par deux parametres tp_arb et 

no_arb, connus a tout instant par Tenvironnement de navigation, et permettant de 
savoir dans quel type de module de Tapplication Tutilisateur travaille (saisie simple, 
saisie de liste. impression, ... et sur quel sujet : article, stocks ...). 

Toutes les structures cartes d'un type donne sont regroupees dans un tableau 
30 (on a done trors tableaux princlpaux), et une table de regroupement. cart[]. regroupe 
les structures pointeurs de chaque tableau. L'ordre des divers types de cartes dans 
ce tableau est le suivant : 
0 Reserv6 



wo 03/085521 ^^PCT/FR03/01019 



1 Saisie des listes 

2 Saisie simple 

3 Reserve 

4 Impressions 
5 5 Reserve 

On decrit ci-apr6s comment referencer un parametre dans une carte. Chaque 
donnee d'une carte est identifiee dans les actions standards sous la forme : type de 
parametre (numerique ou alpha) x 1 000 + numero d'ordre du parametre dans le 
descriptif de la carte, par exemple 58. Le coeur du moteur 71 reconnait que la 

10 donnee provient de la carte en cours et fait une double indirection vers la carte du 
processus en cours, puis vers la 58® position dans cette carte, Ce traitement est 
automatiquement fait par Texecuteur d'actions. fournissant ainsi a celles-ci les 
bonnes valeurs. Ce type d'interpretation est fait non pas par Taction elle-meme. mais 
par le mecanisme d'interpretation des diagrammes du coeur du moteur 71. 

15 Ce principe permet. par exemple, a une meme action de visualisation 

d'afficher des ecrans differents suivant la carte dans laquelle on se trouve. tout en 
conservant les memes param^tres d'appel. II suffit d'avoir modifie auparavant la 
table de parametres indexes. 

Ce type d'interpretation est fait non pas par Taction elle-mSme, mais par le 

20 mecanisme d'interpretation des diagrammes ("cablage" de la carte). En d'autres 
termes. une action comporte des donn^es soit d6crites de fagon specifique soit 
decrites par des parametres (carte + numero dans la carte). 

Si les champs sont des champs de cles. le noeud peut proceder a des tests 
pour verifier leur validite (la fiche doit exister en mode "mise a jour" et ne doit pas 

25 exister en mode "creation"). Les fonctions de saisie standard vont ensuite passer sur 
tous les champs sauf sur les champs de cles. Apres la creation de la cle ou la 
selection d'une fiche en mise a jour, la procedure passe dans une phase de saisie 
courante et traite les champs accessibles. 
Niveau 

30 Une lisVs de structures chaTnees allouees dynamiquement par le systeme 

permet d'obtenir, a tout moment, des informations intdressantes concernant TStat 
courant de Tapplication. Ces structures dites structures niveau, regroupent 
notamment : 



wo 03/085521 




PCT/FR03/01019 



- le norn du diagramme courant (nom) 

- I'index de Taction dans le diagramme courant (nact) 

- le nom de la carte (tp_arb) 

' ('index de la carte dans la table des cartes (no_arb) 
5 Le systeme alloue une telle structure a chaque descente ou a chaque lancement 
d'un diagramme. Les structures sent Iiber6es en fin de diagramme ou apres 
remontee. 

Transferts, insertions et extractions 

L'essentiel des traitements effectues consiste en transferts d'information d'une 
10 zone vers une autre, par exemple d'un champ de fichier, apres la lecture d'un 
enregistrement, vers un champ d'ecran permettant la visualisation de I'information 
consideree. Les structures d'ecrans/fichiers permettent jusqu'a trois codages de 
transferts. Un codage tient sur un unsigned int (32 bits) et a I'aspect suivant : 

type de la donnee (fichier. ecran), nom du fichier ou de I'ecran. nom du 
15 champ. 
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REVENDICATIONS 

1 - Proced6 de generation de logiciel applicatif de gestion d'un processus, 
caracterise en ce qu'il met en oeuvre un logiciel systeme commun a tous les logiciels 

5 applicatifs et en ce qu*il comporte : 

- une etape de representation du processus (32), mettant en oeuvre un tres petit 
nonnbre de classes d'actions ou objets generiques, typiquement inferieur a vingt, 
dans au moins un diagramme de Tapplication, 

- une etape de transcription (33) de chaque objet de chaque diagramme en une 
10 action correspondant a un objet dote d'attributs, chaque classe d'action ou objet 

generique etant, pendant Tetape de transcription, associ§ d une interface de 
saisie de donnees d'application, 

- une etape de transcription des noeuds, embranchements et feuilles (34) de 
chaque diagramme en une action correspondant a un objet dote d'attributs, 

15 - une etape de pre-compilation (35) au cours de laquelle on verifie que les 
attributs des objets necessaires pour la logique de fonctionnement de rapplication 
existent et sont convenablement fournis, en syntaxe, 

- une etape de compilation (36) au cours de laquelle les descriptifs de donnees 
des objets dotes d'attributs sont integres et sont assembles avec le logiciel 

20 systeme, pour obtenir un logiciel applicatif executable, et 

- une 6tape d*ex6cution (37) du logiciel applicatif executable. 

2 ' Proced§ selon la revendication 1, caracterise en ce que, au cours de I'etape de 
transcription d'objets (33), au moins une action lance un traitement complet se 
trouvant a un endroit distant d'une arborescence correspondant audit au moins un 

25 diagramme, et une fois celui-ci termine. retourne a son point de depart. 

3 - Precede selon Tune quelconque des revendications 1 ou 2, caracterise en ce que, 
au cours de T^tape d'execution (37), le logiciel applicatif executable met en oeuvre 
une bibliotheque de gestion du deroulement des processus correspondant audit au 
moins un diagramme. ladite bibliotheque constituant un automate (70) qui gere le 

30 deroulement des processus et execute les operations qui les jalonnent, le 
deroulement des operations etant defini, dans le referentiel applicatif. a Taide de la 
methode (10), en decrivant les flux r6els. 
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4 - Precede selcn Tune quelconque des revendications 1 a 3. caracterise en ce que, 
au cours de Tetape de compilation (36) ou au cours de Tetape d'execution (37), il nnet 
en oeuvre un nnoteur (71) qui comporte un superviseur charge de reconnaitre la 
configuration materielle et de communication. 
5 5 - Precede selon la revendication 4, caracterise en ce que le moteur (71) gdre une 
ou plusieurs bases de donnees d'apres un descriptif des fichiers de donnees fourni 
par le referentiel applicatif. c'est-a-dire une liste des informations contenues dans 
chaque fiche et la liste des index d'acc^s, avec une liste des champs servant ^ 
constituer chacun de ces index, les liens entre des codifications multiples d'un meme 
10 item dans plusieurs sen/ices, plusieurs sites ou plusieurs entreprises. 

6 - Precede selon la revendication 5. caract6ris6 en ce que les bases de donnees 
sent synchronisees selon une frequence determinee par le diagramme, a la 
demande ou avant certains evenements predetermines. 

7 - Precede selon Tune quelconque des revendications 1 a 6. caracterise en ce que 
15 Tetape de transcription d*objets (33) comporte, pour programmer chaque action : 

- une etape de nommage (331) au cours de laquelle on denne un nom ^ ladite 
action, 

- une etape de definition de fonction (332), au cours de laquelle on met ladite action 
en correspondance avec une tache, et, 

20 - une etape de definition d*infermation (333), au cours de laquelle on designe les 
informations qui seront traitees dans Taction. 

8 - Precede selon la revendication 7, caracterise en ce que I'etape de compilation 
(36) remplace le nom d'action denne, au cours de Tetape de nommage (331), par le 
transcripteur, par un index dans une table de taches. 

25 9 - Precede selon Tune quelconque des revendications 1^8, caracterise en ce que, 
au cours des etapes de representation (31) et de transcription (32, 33), ledit au 
moins un diagramme correspond a au moins une arberescence dans laquelle les 
noeuds et feuilles, ou le code est effectu6, sent composes d'actions, les valeurs de 
retour de ces actions determinant le deplacement dans Tarborescence. 

30 
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